1. Technical Field
The present invention generally relates to data processing systems and in particular to web content acquisition in data processing (network) systems.
2. Description of the Related Art
Java Server Pages (JSPs) are an extension to the servlet programming model. One of the key design features of JSP technology is the manner in which a JSP container buffers response content before writing the content to the underlying Servlet response writer. A web container is not able to detect what has been written for a particular JSP until the JSP buffer is filled or the JSP writer is explicitly flushed. When the JSP buffer is filled or the JSP writer is explicitly flushed, the output is written to the underlying Servlet response writer and an associated buffering layer. Only at this point is a web container aware of the content.
In an application server architecture, requests may be made for resources. For example, JSPs may be used to request resources using a Uniform Resource Locator (URL). These resources often comprise a set of operations to be performed, such as includes or forwards to other resources. Generally, only a few of these operations are particularly time consuming, but due to the synchronous nature of the request lifecycle, these operations have a major affect on throughput as a whole.
Potential solutions include utilizing frames or server side includes (SSI), where each portion of the page is a separate distinct request from the client. There is a limitation in these approaches since these distinct requests are unable to be associated with each other and share context related to the original request. The idea of sharing context among all these requests is highly desired because the operations called by the request need access to the original request information sent by the client or set in the processing before the dispatch. Other potential solutions which attempt to overcome the inability to share context suffer from the limitation of synchronized access for each of the fragmented requests. The current methodologies that provide shared context require the server or the proxy to be responsible for aggregating the results of these operations. The aggregation of the results requires additional memory and request processing resources. In addition, holding onto the entire response output until the aggregation is complete prevents the client from ideally starting to retrieve response output as soon as possible. Another downside is the fact that the response output normally written to the client is using up memory while the request thread is left waiting for the other asynchronous actions to complete.